1. Field of the Invention
The present invention relates to maintaining secrecy of unique local IPv6 addresses (i.e., in-site addresses), used by in-site IPv6 nodes for communication within a prescribed site (e.g., a Virtual Private Network Enterprise), during communications by the in-site IPv6 nodes with nodes that are external to the prescribed site, for example via a wide area network such as the Internet.
2. Description of the Related Art
Several attempts are made to safeguard computers having access to a wide area network (such as the Internet) while preserving network-based services for those computers. Of particular interest is the effort to maintaining the secrecy of an IP address used by a network node.
In particular, efforts are underway to expand the realm of private networks for enterprise applications, where a large private site can formed based on private (e.g., secure) connections and routes are established between remote nodes. An example of a larger private site is a Virtual Private Network as described in the Internet Draft by Rosen et al., “BGP/MPLS IP VPNs”, published May 2003. Rosen et al. describes a method by which an IPv4 Service Provider may use an IP backbone to provide IPv4 VPNs (Virtual Private Networks) for its customers. However, Rosen et al. also suggests in Section 11 (“Accessing Internet from a VPN”) that private routes would need to be leaked to the global Internet. Consequently, discovery of a private route would enable an untrusted source to analyze an IP address to discover an internal topology of a VPN.
Unfortunately, all nodes within a private network would need to use global source addresses in order to perform any communications with a remote node via a wide area packet switched network such as the Internet. Hence, VPNs cannot be used to hide global source addresses of VPN users.
One approach for hiding global IPv4 source addresses for VPN users has been to deploy Network Address Translators. Network Address Translators (NATs) were originally developed to delay address depletion by reuse of private IPv4 addresses by network nodes in IPv4-based private networks. The NATs, serving as an interface between a private network and the wide area network such as the Internet, would translate between the prescribed IPv4 addresses and a public IPv4 address used by the NAT as a point of attachment to the Internet. In particular, NATs perform a Layer-3 translation of IP addresses, so that public Internet addresses map to private IP addresses, as described in detail by the Request for Comments 1918 (RFC 1918), published by the Internet Engineering Task Force (IETF), available on the World Wide Web at the IETF website. This mapping has allowed enterprises to map a large number of private addresses to a limited number of public addresses, thus limiting the number of public addresses required by Internet users.
In addition, the use of NATs in a private IPv4 network enables the private IPv4 address used by a network node to be “hidden” from the Internet, especially since the private IPv4 addresses are reserved by the Internet Assigned Numbers Authority (IANA) exclusively for private networks. Exemplary IPv4 network prefixes reserved by the IANA for private networks include the 10/8 prefix (a single Class A network number), 172.16/12 prefixes (a set of 1 contiguous Class B network numbers), and 192.168/16 prefix addresses (a set of 256 contiguous Class C network numbers).
Hence, NATs enable VPN users to hide their IPv4 source addresses, and therefore the VPN topology from external entities.
Unfortunately, NATs suffer from numerous problems, as described in details in numerous publications by the IETF, including RFC 2993. Consequently, there is doubt that NATs will be developed for Internet Protocol Version 6 (IPv6) as defined in RFC 2460.
Consequently, concerns arise for the need for security in deployment of IPv6 networks, and preventing IPv6 addresses from being distributed beyond a prescribed site. For example, the Internet Draft by Hinden et al., entitled “Unique Local IPv6 Unicast Addresses”, published Sep. 24, 2004, describes an IPv6 unicast address format that is globally unique and intended for local IPv6 communications within-site boundaries, while allowing sites to be combined or privately interconnected.
Although Hinden et al. recognizes that unique local IPv6 unicast addresses could be “leaked” outside the site boundaries onto the Internet, Hinden et al. recommends that border router policies and firewall filtering policies be implemented to prevent the local IPv6 unicast addresses from being sent onto the Internet. Hence, a disadvantage recognized by Hinden et al. is that it is not possible to route local IPv6 prefixes on the global Internet with current routing technology.